An IMS/MMD (Multimedia Domain) network or architecture primarily consists of several signaling entities such as proxy-call session control function (P-CSCF), interrogating-CSCF (I-CSCF), serving-CSCF (S-CSCF), and home subscriber service (HSS) which is usually a database or other repository for user or subscriber information such as authorization data, including information related to services provided to a user. Roaming service and mobility are supported by a combination of Session Initiation Protocol (SIP) components such as the signaling entities, P-CSCF, S-CSCF, I-CSCF, and mobile IP components or nodes, such as home agent (HA) and foreign agent (FA). IMS/MMD architecture mandates that there should be security association (SA) between the mobile and P-CSCF. Secure Internet Protocol (IPSec) is one way of providing SA for signaling and media traffic.
In the MMD, service is not provided until an SA is established between the user equipment (UE) and the network. Typically, UE is a Mobile Node (MN). IMS is essentially an overlay to the packet data subsystem (PDS) and has a low dependency on the PDS as it can be deployed without the multimedia session capability. Consequently, a separate SA is required between the multimedia client and the IMS before access is granted to multimedia services.
The primary focus of the IMS/MMD security architecture is the protection of SIP signaling between the subscriber and the IMS. The IMS defines a means of mutual authentication between the subscriber and the IMS, and also specifies mechanisms for securing inter- and intra-domain communication between IMS network elements.
A high level overview of the IMS/MMD security architecture, with numeric labels assigned to security interfaces between the various elements, is shown in FIG. 1. Security interface 1, IMS authentication and key agreement (AKA), is used for authentication between the UE and the HSS in the Home Network. AKA is discussed in more detail below. Security interface 2, IPSec, is used to secure SIP messaging between the UE and the first-hop P-CSCF. Security between the IMS core network elements is shown as security interfaces 3, 4 and 5. Security interfaces 6 and 7 are between IMS core network elements and external IP-Networks. IPSec is applicable both when communication is within the same security domain, and across security domains. The role of IPSec in IMS/MMD is discussed in more detail below.
The current IMS/MMD security architecture addresses the threat of masquerading, whereby an attacker could get unauthorized access to services by pretending to be either a network element or an authorized user. The incorporation of subscriber authentication via authentication and key agreement (AKA) and IPSec, and network node authentication using IPSec prevents this from happening. Also addressed is the issue of eavesdropping, whereby an attacker could compromise the confidentiality of signaling messages or perform passive traffic analysis on these messages. IPSec based encryption may be applied to address this category of threats.
The security architecture shown in FIG. 1 essentially enables Home Network-based authorization for access to IMS services. Although the Visited Network controls the bearer resources used by the UE, IMS authorization can only be obtained from the S-CSCF in the Home Network.
IPSec is a suite of security protocols that has been designed to ensure security of IP layer traffic. The IPSec Encapsulating Security Payload (ESP) protocol supports confidentiality and integrity protection of IP packet payloads, while the IPSec authentication header (AH) protocol supports integrity protection of entire IP packets. The ESP and AH protocol services are provided by establishing security associations (SA) between IPSec enabled network nodes. An SA defines, among other parameters, the integrity protection and encryption algorithms in use between a pair of nodes, and the symmetric keys used by these algorithms. IPSec also defines a key negotiation protocol, IKE, that is used to securely establish the symmetric keys used by ESP or AH SAs.
IPSec ESP and AH protocols may operate in either tunnel or transport mode. In tunnel mode, the entire IP packet is encapsulated within a new IP packet, while in transport mode, additions or modifications are made to the IP payload. Per packet overhead is somewhat higher in tunnel mode in part because it is primarily intended to prevent traffic analysis when used on IPSec gateways that are located between communicating nodes.
IPSec protocols are used extensively in the Internet. The protocol suite is modular in the sense that new confidentiality and integrity protection algorithms can be incorporated without changes to the system architecture. IPSec traffic can be carried on existing IP infrastructure without modification to the underlying physical layer or the interconnection topology. IPSec operation is typically transparent to application layer entities. In the IMS/MMD framework, IPSec is primarily used to provide confidentiality and integrity protection to SIP messages exchanged between the UE and the P-CSCF (security interface 2 in FIG. 1). IPSec ESP, operating in transport mode, is mandated for use in this context. Accordingly, IPSec ESP transport mode SAs are established between a UE and its corresponding P-CSCF once the UE and the P-CSCF have successfully mutually authenticated each other. The IPSec SA establishment procedure is undertaken by IMS AKA.
The following is a list of characteristics of IPSec operating between the P-CSCF and the UE:                IPSec ESP processing is transparent to the SIP applications at the P-CSCF and UE, and is carried out by IPSec modules. These IPSec modules operate outside the scope of the SIP application, although SIP applications may configure SAs within the IPSec modules.        IPSec provides data authentication for the SIP messages; an IPSec ESP protected message received at the UE is guaranteed to have been generated by the P-CSCF (assuming the P-CSCF and UE have not been compromised) and vice versa. Further, the message is guaranteed to not have been replayed by an adversary.        IPSec also provides data confidentiality to SIP messages.        
Assuming uncompromised P-CSCF and UE, IPSec will provide confidentiality to messages generated between them; no eavesdropper will be able to decipher any captured packets.                Since IPSec ESP does not protect the integrity of IP headers, it is necessary for the receiving SIP application to verify that the contact via headers of protected SIP messages match the source IP address in the packet header.        
IPSec may also be employed for security between IMS core network elements interacting either within a single operator's domain (Intra-domain) or across two or more operator's domains (Inter-domain). This leaves the manner of IPSec use at the discretion of the concerned operator(s). Providing inter-domain security involves securing SIP messaging between I-CSCF & P-CSCF (security interface 4 in FIG. 1), between S-CSCF & P-CSCF (security interface 4 in FIG. 1) and between S-CSCF & external IP networks housing SIP application servers (security interface 7 in FIG. 1). In addition, it also involves securing messaging between external SIP application servers and the HSS (Cx-interface) (security interface 6 in FIG. 1). In all cases, IMS Security standards in accordance with 3GPP2 mandates the use of IPSec, in either transport or tunnel mode, using integrity protection as well as encryption. Further, IMS Security standards also require the use of IKE for negotiating security associations between such nodes. IPSec based inter-domain security has the following characteristics:                Use of IKE allows secure negotiation of shared keys between communicating nodes. No predeployment of keys, as required by IMS AKA, is needed.        IKE uses public keys for computation of shared keys using a Diffie-Hellman exchange. Since Diffie-Helman exchanges are vulnerable to man-in-the-middle attacks, the use of public key certificates would be essential to guarantee authenticity of keys.        Use of tunnel mode security associations across operator networks allows the use of security gateways between operator networks.        
This allows protection of operator networks from traffic analysis attacks, since tunnel mode SAs encrypt IP headers of packets generated at IMS nodes.
Intra domain security (security interfaces 3 & 5 in FIG. 1) is left open to the administrative authority for the domain. IPSec based confidentiality and integrity protection is an option, although no particular key distribution/negotiation mechanism or SA mode is mandated.
One IPSec transport mode ESP is IMS AKA which is an authentication protocol defined for use between the UE and the HSS. IMS AKA is based on the SIP security mechanism agreement protocol. In this protocol, all security parameters are exchanged between the UE and the HSS using SIP.
FIG. 2 shows the constituent SIP message flows, involving the UE, P-CSCF, I-CSCF, S-CSCF & HSS, of IMS AKA. IMS AKA is piggybacked on top of SIP registration/response messages along with the associated key distribution process. Two sets of Registration/Response messages are required. At the end of the first set of messages, IPSec SAs are established between the UE and the P-CSCF. The UE authenticates the network after receiving the 4xx Auth_Challenege message while the network authenticates the UE after receiving the second Register message.
The following are characteristics of IMS/AKA:                Authentication is achieved between the UE and its Home Network even though the SIP messaging is transported over the Serving (Visited) Network.        
This allows Home Network-based control of access to IMS resources, while the Visited Network has control of bearer resources over the packet data subsystem (PDS).                SIP Registration/Response messages are used to transport the IMS/AKA protocol payloads. These messages are sent from the UE to the S-CSCF and vice versa. The S-CSCF queries the HSS to obtain security related parameters for the UE.        The UE and the HSS share a long term key (K). This key is only used during the IMS/AKA protocol operation and not during IPSec processing at the UE.        IMS AKA uses a challenge response mechanism to authenticate the UE to the Home Network. The UE uses K to compute a response to a challenge sent by the S-CSCF via the P-CSCF. The P-CSCF plays no role in challenge generation aside from acting as a forwarding element.        The Network is authenticated to the UE by verification of a message authentication code (MAC) sent by the S-CSCF via the P-CSCF. The MAC, at layer 2 link, or L2, is verified using K at the UE.        IPSec ESP SAs between the UE and its current P-CSCF are established during the IMS AKA based Registration process. The HSS uses K to derive the integrity key (IK) and encryption key (CK) for use in an IPSec SA. A fresh IK, CK pair is used to setup new IPSec SAs whenever a new IMS AKA procedure occurs between the UE and its current P-CSCF.        IK, CK pairs are transported to the visited P-CSCF during the course of the IMS AKA procedure using a SIP response message from the Home Network's S-CSCF. K is never sent to the P-CSCF. Thus, even IK, CK are compromised for a particular SA, K will not be compromised.        The IPSec SAs always have a lifetime that is slightly greater than the SIP Registration lifetime. This allows new SIP Registrations to make use of preexisting SAs whenever possible.        
SIP packets exchanged between the UE and the P-CSCF are protected using pairs of unidirectional ESP transport mode SAs. Thus, the UE has an inbound SA for packets received from the P-CSCF and an outbound SA for packets sent to the P-CSCF. The P-CSCF also has a similar pair of SAs for each UE with which it communicates. These SAs are established between the UE and the P-CSCF using the IMS AKA protocol as discussed above.
Transport mode operation of IPSec ESP for IPv4, shown in FIG. 3, includes the operation of IPSec ESP for the case of a transmission control protocol (TCP) payload. The operation for user datagram protocol (UDP) payloads is identical, except that the UDP protocol number replaces the TCP protocol number in the packets. SIP messaging may be carried over either UDP or TCP. Hence, the SIP headers and payload would be carried in the Data portion of the packet shown in FIG. 3.
Once SAs are established, every SIP packet sent from the UE to the P-CSCF is processed by IPSec, as follows:
1. Assuming a UDP transport, the SIP packet generated at the UE is encapsulated within a UDP payload that, in turn, is framed within an IP payload. This IP packet is processed by the outbound SA at the UE.
2. An ESP trailer containing pad bytes and payload information is appended to the IP payload that contains the SIP datagram. The IP payload and the ESP Trailer are then encrypted using one of the algorithms mandated by IMS/MMD. The algorithms mandated at present are DES-EDE3-CBC and AES-CBC.
3. An ESP header containing SA specific information is inserted between the IP payload and the original IP header.
4. The new IP payload, from the ESP header to the ESP trailer, is integrity protected by one of the IMS/MMD mandated algorithms. These are HMAC-MD5-96 or HMAC-SHA-1-96 at present. The integrity protection information is stored in the ESP Authentication field that is appended at the end of the IP datagram.
5. The IP datagram with the newly added ESP fields is now transmitted to the P-CSCF over the PDS layer.
6. On receiving the IP datagram, the P-CSCF determines which inbound SA to use by consulting the ESP header and the IP header's destination IP address.
7. First, the P-CSCF checks the packet integrity by using the ESP authentication header field and the integrity protection key specified by the selected SA.
8. Once integrity is verified, the P-CSCF uses the decryption key specified by the SA to decrypt the IP payload. Once decryption is completed, the ESP related headers are removed and the packet is eventually transferred over to the SIP application.
SIP packets transmitted from the P-CSCF to the UE are also processed in a similar manner using the corresponding outbound SA at the P-CSCF and the inbound SA at the UE.
The P-CSCF forwards received SIP packets from the UE to other IMS network elements and vice versa. SIP signaling packets thus need to be protected as they transit or travel within the IMS core network. IMS Security standards specify IPSec as a means to achieve inter-domain security for signaling messages exchanged between inter-domain network elements. In the case where IPSec is not available, IMS Security standards also suggest the use of transport layer security (TLS) as a means to achieve hop-by-hop security between network elements. In cases where the IMS network elements are within the same network operator's domain, IMS Security standards leave the security mechanisms to the discretion of the network operator.
The IMS/MMD security framework does not specify a means to secure media at the IMS layer but instead focuses on securing SIP based signaling messages. Media sessions do not flow through the IMS core network elements such as the P-CSCF, I-CSCF and S-CSCF and are thus outside the scope. IP multimedia sessions will traverse the PDS in the form of user data packets. Some security is provided to data packets at the Radio Access (RA) level and the IP network level as shown in FIG. 4.
RA level security may incorporate air interface encryption at the discretion of the network provider, to support confidentiality requirements. However, this does not provide end-to-end security to the media.
IPSec may be supported between the Home Agent and Foreign Agent at the discretion of the network operator(s). Again, this does not provide end-to-end security.
End-to-end security may be added in accordance with user requirements but the mechanisms for these are not, at present, specified in the 3GPP2 standards. End-to-end security may be required based on the level of confidence the user has in the network security mechanisms or on the nature of the media content. However, in some situations, end-to-end security may interfere with government regulations requiring Lawfully Authorized Electronic Surveillance.
Alternative mechanisms are available for performing end-to-end security.
IPSec: Network layer end-to-end security may be provided by leveraging IPSec services already present at the UE. In this case, SAs would be established directly between UEs, and no support would be required from the PDS. Applications generating media content at the UEs would not be impacted by the introduction of IPSec and the media streaming protocol would be unaware of the presence of IPSec as well.
SRTP: The Secure Real-time Transport Protocol is a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP. As with the case of IPSec, no PDS support would be required. However, applications generating media content would need to support SRTP.
IPSec impacts different architecture alternatives in terms of P-CSCF placement. One alternative has P-CSCF in the home network core. For this alternative, we examine two distinct cases for two mobility protocols: i) when MIPv6 is used, and ii) when MIPv4 is used in FA mode. FIG. 5 illustrates the scenario where MIPv6 is deployed. In such a scenario, two tunnels are required from the mobile node (MN): one is an MIPv6 tunnel between MN and HA, and the other one is a tunnel between MN and P-CSCF. Mobile Node requires an IPSec SA be established with the home P-CSCF whether it is bootstrapping or changing a P-CSCF while roaming. Also, depending upon how the SAs are created, Mobile Node may require establishing a new SA with the same P-CSCF when Mobile Node changes to a new PDSN. Therefore, more tunnel overhead is added at the Mobile Node, in addition to MIPv6 tunnel.
Depending upon the location of Mobile Node and access network conditions, IPSec SAs establishment may have some impact on handoff performance. All SIP signaling including registration does need to be exchanged via IPSec SAs since P-CSCF is in the critical path. Also, IPSec SA establishment needs to be fast enough so that the session can be maintained while MN is connecting to a new PDSN. However, media is not necessarily exchanged via IPSec Sas.
There are some issues during handoff. For example, IPSec SA establishment delay may be high when Mobile Node is visiting a remote network. This may not be an issue during bootstrapping but may affect the handoff performance if this delay is too long or large. A new SA must be established while changing PDSNs. Usually, IPSec SAs are bound to interface IP address. Therefore, when interface IP address changes, i.e. Mobile Node attaches to another PDSN, a new IPSec SA needs to be established, unless SA is bound to some permanent identifier. Further, P-CSCF changes during handoff. In the scenario where visited networks are assigned with different P-CSCFs, Mobile Node needs to create a new IPSec SA while changing the network. However, this may not be the usual case.
IPSec may also impact the core network, mostly at the system level, if proper planning is not done during deployment. One such impact is the number of IPSec Tunnels employed. In a large network, there are many communication paths that need to be set up during a service session for signaling exchange, media transmission, and management data exchange with the home network. Without careful planning, the number of IPSec tunnels required may increase as more applications as well as devices are deployed. The system performance may thus be seriously degraded due to the opening of an excessive number of IPSec tunnels in the core network.
IPSec may also impact the core network with respect to Packet Fragmentation. When IPSec is applied to a data packet at IP Layer 3, a header or trailer or both needs to be added to the packet to let the receiving end know that IPSec algorithms need to be invoked. These additions increase the length of the packet and cause the packet to be split into two packets (known as IP fragmentation) for transmission. For example, if the original packet size is 1,490 bytes, it will increase to 1,544 bytes after adding ESP headers, trailers information, and MAC value. The packet thus needs to be fragmented into two packets when Ethernet is used. These additional packets impose additional processing burden on the system and thus downgrade the overall performance of the network. This may add substantial delay if a large number of requests come from multiple Mobile Nodes simultaneously.
FIG. 6 shows the tunnels that are required in case of MIPv4. The number of tunnels required from the mobile node in such a scenario is only one, e.g., IPSec tunnel between MN and P-CSCF, since the MIP tunnel is between FA and HA. However, fast IPSec SA establishment will be necessary to achieve better handoff performance. Accordingly, this architecture has same type of IPSec issues as described above for MIPv6.
Another alternative architecture in terms of P-CSCF placement is the placing of P-CSCF in the visited network. For this alternative, we also examine two distinct cases for two mobility protocols: i) when MIPv6 is used and ii) when MIPv4 is used in FA mode. FIG. 7 illustrates the scenario where MIPv6 is deployed. In such a scenario, two tunnels are required from the mobile node: one is MIPv6 tunnel between MN and HA and the other one is a tunnel between MN and P-CSCF. Mobile Node requires establishing an IPSec SA with the visited P-CSCF whether it is bootstrapping or changing a P-CSCF while roaming. The only difference with the previous architecture would be that the P-CSCFs are all in the visited domain.
FIG. 8 shows the tunnels that are required in case of MIPv4. As with the above described architecture, only one tunnel is required from the Mobile Node in this scenario, between Mobile Node and P-CSCF. Again, fast IPSec SA establishment will be necessary to achieve better handoff performance.
Yet another alternative architecture in terms of P-CSCF placement is the placing of P-CSCF in the visited network subnets. For this alternative, we again examine two distinct cases for two mobility protocols: i) when MIPv6 is used and ii) when MIPv4 is used in FA mode. FIG. 9 illustrates the scenario where MIPv6 is deployed. As with the above architectures, two tunnels are required from the mobile node: one is an MIPv6 tunnel between MN and HA and the other one is a tunnel between MN and P-CSCF. This architecture has major differences with the previous two architectures in that Mobile Node needs to establish a new IPSec SA each time Mobile Node moves to a new subnet. In other words, each time Mobile Node changes a PDSN, Mobile Node connects to a new P-CSCF. Therefore, IPSec SA establishment delay may be high since Mobile Node has to perform SIP registration with normal AKA procedure each time Mobile Node moves to a new subnet. Hence handoff performance is impacted since media will not start flowing through the new PDSN unless a successful authentication is done, including the establishment of an SA between Mobile Node and P-CSCF.
IPSec may also impact the visited network, mostly at the system level, if proper planning is not done during deployment. For example, in a highly congested visited network, there may be a large number of mobile nodes that need to set up IPSec SAs either during bootstrapping or during a service session handoff. Without careful planning, the number of IPSec tunnels required may increase to a large number as the number of subscribers increases. The system performance may thus be seriously degraded due to the opening of an excessive number of IPSec tunnels in the visited network. Eventually, this may add more delay during SA initialization.
Further, as with the above architecture alternatives, IPSec may also impact the visited network with respect to Packet Fragmentation.
FIG. 10 shows the tunnels that are required in case of MIPv4. The issues with respect to the P-CSCF in the visited network subset in the MIPv4 protocol are the same as those with the visited network, described above. However, there is less impact in terms of tunnel overhead at the Mobile Node since only one tunnel is established, except when accessing from wi-fi networks.
IPSec tunnel establishment delay at the P-CSCF can add significant overhead in both signaling and media on a session transfer during handoff. In particular, some architectures require Mobile Node to register during every subnet change. While signaling for registration and media transfer can happen simultaneously from Mobile Node, media transfer cannot be resumed via new PDSN until SAs are established between P-CSCF and MN. According to IMS/MMD standards, the access control policy in the visited network will only allow the media to flow via new PDSN once the registration is successful in the new visited network, i.e., IPSec SAs are established between MN and new P-CSCF. Thus, an implicit dependency exists between SIP registration and media transfer even though media may not be protected via IPSec SAs. Unfortunately, MIP binding update procedure may also add significant delay to the media depending upon the location of HA.
As discussed above, IMS/MMD security framework defines the security mechanisms between the UE, i.e., Mobile Node, and P-CSCF and is called IMS AKA. The role of IMS AKA in IMS/MMD framework is as follows. During the registration procedure, P-CSCF receives a new pair of keys (e.g., IK and CK) for a Mobile Node from S-CSCF, along with other parameters. These keys are used to establish the SA with the new UE. Although UE may be registered with the same S-CSCF while changing the subnet, ideally the keys generated for new P-CSCF should be different.
Therefore it is evident that the above IMS AKA registration procedure requires time and can add significant delay during P-CSCF handoff. Additionally, multiple tunnels at the Mobile Node may add more overhead to the overall handoff procedure. Thus IPSec optimization is required, that is, a mechanism by which handoff delay can be minimized while not compromising the IMS/MMD security and also protecting the media if required by certain applications.